1. Field of the Invention
The present invention relates to computer software, and deals more particularly with improved navigation of content in a user interface that has been rendered in a content aggregation framework (such as in a portal page provided by a portal system).
2. Description of the Related Art
The popularity of distributed computing networks and network computing has increased tremendously in recent years, due in large part to growing business and consumer use of the public Internet and the subset thereof known as the “World Wide Web” (or simply “Web”). Other types of distributed computing networks, such as corporate intranets and extranets, are also increasingly popular. As solutions providers focus on delivering improved Web-based computing, many of the solutions which are developed are adaptable to other distributed computing environments. Thus, references herein to the Internet and Web are for purposes of illustration and not of limitation.
The early Internet served primarily as a distributed file system in which users could request delivery of already-generated static documents. In recent years, the trend has been to add more and more dynamic and personalized aspects into the content that is served to requesters. One area where this trend is evident is in the increasing popularity of content frameworks such as those commonly referred to as “portals” (or, equivalently, portal systems or portal servers). A portal is a type of content framework that serves as a gateway, or focal point, for users to access an aggregation or collection of content from multiple independent sources. A portal provides its users with a user interface structured as a Web page. This Web page is known as a “portal page”, and is normally structured as a single overview-style page (which may provide links for the user to navigate to more detailed information). Alternatively, portal pages may be designed using a notebook paradigm whereby multiple pages are available to the user upon selecting a tab for that page. Some experts predict that portal pages wall become the computing “desktop” view of the future. (While discussions herein are primarily in terms of portals, portal pages, and portlets, this is for purposes of illustration only. Other content aggregation frameworks providing similar functionality may be substituted without deviating from the scope of the present invention.)
Portal pages offer users Web pages that contain content from many different sources, and provide rich content to users in a compact form. Sources of portal page content include Internet sites, a company's intranet, news groups, applications, and other content management feeds. Many portals allow users to design a personalized version of the portal page, whereby the user can tailor the content, the layout, and/or the presentation attributes (such as color, font, etc.) of the page to his or her own preferences.
Portals are commonly designed using a component model that allows plugging components referred to as “portlets” (or, alternatively, components using a similar abstraction) into the portal infrastructure. Each portlet is responsible for obtaining a portion of the content that is to be rendered as part of the complete portal page for the user.
A portal operates as a Web application, and the portlets serve as application interfaces to their respective function. During operation, the portal calls the portlets, which return markup language (such as Hypertext Markup Language, or “HTML”) syntax to the portal. By convention, the portlet is invoked through its “service” method. The markup stream returned from this invocation encapsulates the result of the portlet's execution. The portal's content aggregation process aggregates the markup streams from the invoked portlets into a single stream of markup, and returns this stream as a page for rendering with the user's browser (or other user agent). Once the content created by the portlets has been aggregated with other markup language syntax, the result is a Web page whose content is well suited for the needs of the portal page's human user.
FIG. 1 provides an example of a portal page 100 which includes three portlets 120, 130, 140. Portlet 120 in this example displays news headlines. Portlet 130 shows stock information for the user's favorite stocks, and portlet 140 displays the current weather and weather forecast for the user's selected city.
Actual portal pages may be much more rich in content than the example in FIG. 1. A portal page may also contain navigation areas within the page. In the portal page 100, the topmost graphic 110 which displays a portal logo 111 is a navigation bar which includes links 112, 113, 114 to other portal functions.
Portals are typically viewed with “north”, “south”, “east”, and “west” navigation areas. The center area of the page is then reserved for the aggregation of portlet content. The majority of portals offer only north and south navigation areas. Other portals, such as the WebSphere® Portal Server from the International Business Machines Corporation (“IBM®”), offer just a north navigation area. (“WebSphere” and “IBM” are registered trademarks of the International Business Machines Corporation.) The remainder of the view may then be used for portlet content. Still other portals provide navigation areas designated as “top” and “left” (which are analogous to the north and west navigation areas of other portals). In general, any combination of navigation areas and content area may be supported, with the visual appearance and functional content of a particular portal page determining how many navigation areas there are, and what their placement should be.
When content on the portal page includes elements that can receive the focus, such as input fields and links, the declaration order of these elements determines the order in which the elements will be visited when the user navigates the page using the tab key. This order can be overridden by assigning the elements a numeric visitation order, which is specified as the value of a TABINDEX attribute within the markup language syntax from which the page is rendered. When the TABINDEX attribute is used, the tab order will be determined by these values for each element, independent of the actual position of the field or link within the rendered page.
A problem therefore arises. An individual portlet's output markup stream may specify TABINDEX values without regard to this output stream being aggregated with other portlet content (i.e. with other output streams), where that other portlet content may also contain its own TABINDEX specifications. Navigation areas may also contain TABINDEX specifications. Since each portlet and navigation area is an independent entity, and the portlets and navigation areas making up a particular portal page may therefore originate from multiple sources, there is no coordination among the TABINDEX settings that may be specified. If pressing the tab key causes the current cursor position (or the window focus) to move in an apparently erratic manner (jumping unexpectedly from one navigation bar to another or jumping across a portlet's entire output area, for example), the human user may become confused or irritated, and the user's productivity may suffer as he or she attempts to work with the portal page.
One way to address this problem might be for the portal aggregation process that is assembling the portal page to scan all of the page content (i.e. the aggregation of markup streams) and insert sequentially-ordered TABINDEX attribute values into each link or form field tag (as well as into other tags that may receive the focus). However, scanning each generated portal page in this manner would be very expensive in terms of computational overhead at the portal, lowering server performance and likely causing a severe processing bottleneck. Thus, this is not a viable solution.
Accordingly, what is needed is a way to improve navigation of content that has been rendered in a content aggregation framework.